Не так давно компания Microsoft опубликовала окончательную модель лицензирования нового поколения семейства серверных ОС Windows Server 2012, где достаточно существенно поменялись правила лицензирования ОС под виртуализацию.

Напомним, как обстояли дела с лицензированием операционных систем Windows Server 2008 R2:

Как видно из таблицы лицензия на издание Windows Server 2008 R2 Standard давала право на запуск одной хостовой машины и одной виртуальной, издание Enterprise - возможность запуска 4-х экземпляров под одной лицензией плюс хостовая платформа, а издание Datacenter позволяло запускать неограниченное количество экземпляров виртуальных машин в пределах одного лицензированного сервера.

Недавно мы уже упоминали о том, что для продукта Microsoft System Center 2012 Suite уже было убрано издание Enterprise, теперь же пришла очередь Windows Server 2012 лишиться этого издания. Теперь в новой ОС, с точки зрения виртуализации, осталось лишь 2 издания - Standard и Datacenter:

Издания Essentials и Foundation не предполагают каких-либо прав на виртуализацию и предназначены для совсем малых предприятий, поэтому здесь мы их рассматривать не будем, а сфокусируемся на изданиях Standard и Datacenter. Обратите также внимание, что исчезло издание Web Server Edition.

Во-первых, издание Windows Server 2012 Standard ничем не отличается по функциональности от издания Datacenter (Full Windows Server functionality), а поэтому оно подорожало. А именно в издании Windows Server 2012 Standard появилась следующая функциональность, которой не было в Windows Server 2008 R2:

• Windows Server Failover Clustering
• BranchCache Hosted Cache Server
• Active Directory Federated Services
• Additional Active Directory Certificate Services capabilities
• Distributed File Services (support for more than 1 DFS root)
• DFS-R Cross-File Replication

Соответственно, с точки зрения функционала мы имеем, по-сути, одно издание данной ОС. А дифференцируются эти издания следующим образом: Standard позволяет запустить до 2-х виртуальных машин под одной лицензией, а издание Datacenter - неограниченное количество ВМ.

Одна лицензия Windows Server 2012 Standard или Datacenter приобретается на 2 процессора физического хост-сервера. Таким образом, если у вас 4-процессорный сервер, вы можете:

• купить 2 лицензии Windows Server 2012 Standard и запустить 4 виртуальные машины на нем (неважно на платформе Microsoft Hyper-V или VMware vSphere)
• купить 2 лицензии Windows Server 2012 Datacenter и запускать сколько угодно виртуальных машин на нем (Hyper-V или vSphere)

Понятно, что 4 виртуальные машины на четырехпроцессорном сервере никто исполнять не будет, поэтому в случае увеличения количества ВМ на сервере можно пойти двумя путями, в зависимости от экономической целесообразности. Например, вы приобрели 2 лицензии на Windows Server 2012 Standard (1 лицензия = 2 CPU сервера) на четырехпроцессорный сервер, и у вас виртуальных машин стало больше четырех (т.е. больше того, что позволяет лицензия). В этом случае вы можете:

• Докупить еще лицензий на Windows Server 2012 Standard, каждая из которых позволит дополнительно запускать по 2 виртуальные машины на данном сервере
• Если у вас есть действующая подписка Software Assurance, можно сделать Software Assurance Step-Up апгрейд на Datacenter Edition и уже запускать сколько угодно виртуальных машин на этом сервере

Рассмотрим примеры:

1. У вас есть один двухпроцессорный сервер, на котором будет запущено 10 виртуальных машин и вам больше не потребуется увеличивать их количество на этом сервере. Посчитаем стоимость покупки Standard и Datacenter на этот сервер:

• 5 лицензий (каждая на 2 CPU хоста) на Windows Server 2012 Standard дают право исполнять 10 виртуальных машин и стоят 5 х 882 = $4 410
• 1 лицензия (на 2 CPU) на Windows Server 2012 Datacenter дает право исполнять эти 10 виртуальных машин и стоит $4 809

В этом случае лицензии на Windows Server 2012 Standard получается покупать выгоднее.

2. У вас есть один четырехпроцессорный сервер, на котором будет запущено 30 виртуальных машин. Посчитаем стоимость покупки Standard и Datacenter на этот сервер:

• 15 лицензий Standard (на 30 машин) обойдутся в: 15 х 882 = $13 230
• 2 лицензии Datacenter (на 4 CPU) обойдется в: 2 х 4 809 = $9 618

В этом случае уже выгоднее издание Windows Server 2012 Datacenter.

Общее правило для издания Standard таково - сначала вы покрываете требуемыми лицензиями все физические процессоры (сокеты), а далее докупаете лицензии на 2 виртуальные машины. То есть, для 10-процессорного сервера нужно купить минимум 5 лицензий, а для 20 виртуальных машин (неважно сколько физ. процессоров у хоста, если оно меньше 20) - минимум 10 лицензий.

Таким образом, все просто - если маленький коэффициент консолидации ВМ на хосте - нужно покупать Standard, если большой - Datacenter. При этом различия в функциональности нет.

Про даунгрейд с 2012 на 2008 R2 тоже все достаточно понятно. Можно сделать даунгрейд Datacenter на Datacenter, а Standard на Enterprise или Standard, при этом правила лицензирования виртуальных машин остаются от купленного Windows Server 2012:

Правила обмена лицензий Windows Server 2008 R2 на лицензии Windows Server 2012

Правила эти просты:

• каждая лицензия Windows Server 2008 R2 Enterprise (с действующей подпиской Software Assurance) обменивается на 2 лицензии Windows Server 2012 Standard (т.е. всего на 4 ВМ - как и было раньше).
• лицензия Standard 2008 R2 обменивается на Standard 2012 в соотношении 1 к 1.
• лицензия Datacenter 2012 покрывает 2 процессора, а Datacenter 2008 R2 - один процессор, поэтому за две старых 2008 R2 дают одну новую Datacenter 2012.

Более детальная информация представлена в документе "Windows Server 2012 Licensing & Pricing FAQ".

Иногда в целях безопасности необходимо настроить время, по прошествии которого если клиент vSphere Client не используется, требуется прервать сессию работы с VMware vCenter. Как подсказывает нам William Lam, сделать это можно двумя способами:

• Заданием аргумента при запуске исполняемого файла VpxClient.exe (vSphere Client)
• В конфигурационном файле VpxClient.exe.config на рабочей станции, где установлен vSphere Client

В первом случае мы задаем параметр inactivityTimeout в свойствах ярлыка vSphere Client, где устанавливаем время в минутах, после которого при неактивности клиента будет показан диалог о необходимости повторного логина:

Во втором случае нужно найти файл VpxClient.exe.config, который находится в следующих местах в зависимости от версии ОС:

• 32bit - %PROGRAMFILES%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher
• 64bit - %PROGRAMFILES(x86)%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher

Открываем этот XML-файл и прямо перед окончанием секции cmdlineFallback добавляем следующую секцию:

<inactivityTimeout>X</inactivityTimeout>

Если вы задали значение 1, то после неактивности в течение 1 минуты, будет показано следующее сообщение:

Также Вильям указывает на еще 2 интересных параметра, которые могут быть заданы как на уровне аргументов исполняемого файла клиента, так и в VpxClient.exe.config:

• -expAll либо добавление секции <expAll /> - при открытии vSphere Client ваше Inventory хостов и виртуальных машин будет полностью раскрыто
• -noPlugins либо добавление секции <noPlugins /> - при запуске клиента все плагины будут отключены

Виктор прислал мне презентацию от того самого Ивана, который на одной из юзер-групп VMware рассматривал особенности дизайна и проектирования виртуальной инфраструктуры VMware vSphere. Часть, касающаяся виртуализации различных типов нагрузок в гостевых ОС виртуальных машин показалась мне очень интересной, поэтому я решил перевести ее и дополнить своими комментариями и ссылками. Итак, что следует учитывать при переносе и развертывании различных приложений в виртуальных машинах на платформе vSphere.

Наш с вами коллега, Анатолий Вильчинский, проводит в ближайшие дни 2 интересных вебинара по продукту номер 1 для создания отказоустойчивых хранилищ под виртуализацию - StarWind iSCSI SAN.

Первый вебинар, который пройдет 11 июля в 19-00 по Москве, посвящен версии продукта StarWind 5.8 (есть также бета 5.9) для серверов VMware vSphere и называется "Storage Evolution & StarWind v5.8 Solutions ".

Зарегистрироваться.

На следующий день, 12 июля в 22-00 по Москве, вы можете послушать новости о продукте StarWind Native SAN for Hyper-V, который позволяет построить недорогую инфраструктуру отказоустойчивых хранилищ на базе всего лишь двух серверов виртуализации, которые будут одновременно и хост-серверами и хранилищами, что позволит вдвое сократить затраты на оборудование. Итак, регистрируемся на вебинар "StarWind Solutions for Hyper-V Environments".

Зарегистрироваться.

Приходите, будет интересно. Тем более, что Анатолий ответит на все ваши вопросы на русском языке.

Компания Veeam Software известна не только продуктом номер 1 Veeam Backup and Replication для резервного копирования виртуальных машин VMware vSphere и Microsoft Hyper-V, но и бесплатными средствами для управления виртуальной инфраструктурой, например, Veeam Backup Free (бывший FastSCP) или Veeam ONE Free Edition.

Одно из них - Veeam Extended Generic Report Library вышло совсем недавно. Это бесплатная библиотека из четырех отчетов, работающая на движке Microsoft SQL Server Reporting Services под Microsoft System Center Operations Manager 2007 R2 или Microsoft System Center 2012 Operations Manager, которая позволяет анализировать состояние и производительность объектов инфраструктуры – как для физической, так и для виртуальной среды. Библиотека может работать с любыми пакетами управления (MP): для создания подробных отчетов с возможностями, которые недоступны в стандартной библиотеке отчетов Microsoft System Center, достаточно настроить правила и задать нужные параметры отчетов.

Расширенная библиотека отчетов Veeam включает такие отчеты, как:

• Veeam Alert Statistics Report – анализ статистики срабатывания оповещений в двух режимах – по правилам/мониторам и по объектам (пример).
• Veeam Generic Performance Top (Bottom) N Report – визуальное представление объектов инфраструктуры, экземпляров, или и тех и других, для выбранного показателя производительности (пример).
• Veeam Performance Report – визуальное представление значений показателей производительности в диаграммах и таблицах (пример).
• Veeam Performance Details Report – анализ тенденций с помощью подробных данных о производительности (пример).

Скачать бесплатную библиотеку Veeam Extended Generic Report Library можно по этой ссылке.

Мы уже писали о новом механизме высокой доступности VMware High Availability (HA), который появился в VMware vSphere 5 и работает на базе агентов Fault Domain Manager (FDM). Как известно, вместо primary/secondary узлов в новом HA появились роли узлов - Master (один хост кластера, отслеживает сбои и управляет восстановлением) и Slave (все остальные узлы, подчиняющиеся мастеру и выполняющие его указания в случае сбоя, а также участвующие в выборе нового мастера в случае отказа основного).

В нашей статье об HA было описано основное поведение хостов VMware ESXi и кластера HA в случае различных видов сбоев, но Iwan Rahabok сделал для этих процессов прекрасные блок-схемы, по которым понятно, как все происходит.

Если хост ESXi (Slave) не получил хартбита от Master, которые он ожидает каджую секунду, то он может либо принять участие в выборах, либо сам себя назначить мастером в случае изоляции (кликабельно):

Если хост ESXi (Master) получает heartbeat хотя бы от одного из своих Slave'ов, то он не считает себя изолированным, ну а если не получает от всех, то он изолирован и выполняет Isolation Responce в случае, если нет пинга до шлюза. Работающим в разделенном сегменте сети он себя считает, когда он может пинговать шлюз. Проверка живости хостов (Slaves) производится не только по хартбитам, но и по datastore-хартбитам (кликабельно):

Все просто и понятно. Иван молодец.

Если у вас в виртуальной инфраструктуре большой набор хранилищ, хостов VMware ESXi и виртуальных машин, то легко не заметить один интересный момент - бесполезные vswp-файлы для виртуальных машин, размещенные в папке с ВМ. Выглядят они как <что-то там>.vswp.<номер чего-то там>:

Как видно из картинки, файлы эти не маленькие - размер vswp равен объему памяти, сконфигурированной для виртуальной машины (vRAM) без Reservation для RAM (если есть reservation, то размер vswp = vRAM - Reservation). Так вот эти файлы с номерами - это ненужный мусор. Образуются они тогда, когда хост ESXi падает в PSOD с запущенными виртуальными машинами.

Эти файлы, понятно дело, надо удалить. Для этого удобнее всего использовать PowerCLI:

dir vmstores:\ -Recurse -Include *.vswp.* | Select Name,Folderpath

Пример вывода мусорных файлов vswp с путями:

Ну а дальше сами знаете, что с ними делать.

На сайте проекта VMware Labs появилась новая интересная утилита Guest Reclaim, позволяющая уменьшить размер "тонкого" (thin provisioned) диска виртуальной машины из гостевой ОС Windows, истребовав нулевые блоки. Напомним, что когда тонкий диск виртуальной машины растет по мере наполнения данными, а потом вы эти данные в самой гостевой системе удаляете, его размер не уменьшается.

Один из способов уменьшить диск машины в VMware vSphere - это использовать утилиту sdelete для очистки блоко и перемещение виртуальной машины на другое хранилище средствами Storage vMotion. Однако, если вы прочтете нашу статью про datamover'ы при Storage vMotion и вспомните, что VMware vSphere 5 использует унифицированные блоки размером 1 МБ для всех хранилищ, то поймете, что этот способ больше не работает, поскольку в датамувере fs3dm не реализована процедура вычищения блоков целевого виртуального диска.

Есть конечно способ отключить fs3dm и, все-таки, уменьшить виртуальный диск машины на ESXi, однако это не очень удобная процедура. Поэтому сотрудники VMware и сделали удобную консольную утилитку Guest Reclaim, которая позволяет уменьшить диск с файловой системой NTFS.

Поддерживаются следующие гостевые ОС:

• Windows XP
• Windows Vista
• Windows 7
• Windows Server 2003
• Windows Server 2008

Запускать утилиту нужно из гостевой ОС, в которой есть диски, являющиеся тонкими. Чтобы просмотреть список тонких дисков используйте команду:

GuestReclaim.exe -list

Если ничего не найдено - значит первые 16 дисков не являются тонкими или у вас ESXi 5.0 и ниже (читайте дальше). VMware предлагает приступать к уменьшению диска, когда у вас разница между размером VMDK и файлами гостевой ОС хотя бы 1 ГБ, при этом для работы самой утилиты может потребоваться дополнительно 16-100 МБ свободного места. Также перед началом использования утилиты рекомендуется запустить дефрагментацию диска, на которую тоже может потребоваться свободное место (будет расти сам VMDK-файл).

Команда, чтобы уменьшить тонкий VMDK-диск за счет удаления нулевых блоков, выполняемая из гостевой ОС:

guestReclaim.exe --volumefreespace D:\

Еще одно дополнение - утилиту можно использовать и для RDM-дисков.

А теперь главное - утилита работает только в случае, если hypervisor emulation layer представляет гостевой ОС диски как тонкие. В VMware ESXi 5.0, где Virtual Hardware восьмой версии, такой возможности нет, а вот в ESXi 5.1, где уже девятая версия виртуального железа - такая возможность уже есть. Соответственно, использовать утилиту вы можете только, начиная с VMware vSphere 5.1 (бета сейчас уже у всех есть), а пока можно использовать ее только для RDM-дисков.

Из ограничений утилиты Guest Reclaim:

• Не работает со связанными клонами (Linked Clones)
• Не работает с дисками, имеющими снапшоты
• Не работает под Linux

Из дополнительных возможностей:

• Поддержка томов Simple FAT/NTFS
• Поддержка flat partitions и flat disks для истребования пространства
• Работа в виртуальных и физических машинах

FAQ по работе с утилитой доступен по этой ссылке. Скачать утилиту можно тут.

Мы уже писали о том, что в продукте номер 1 - vGate R2, предназначенном для защиты виртуальной инфраструктуры VMware vSphere, имеются, помимо всего прочего, втроенные средства контроля целостности и доверенной загрузки виртуальных машин. Реализуется это средствами одной из политик безопасности для хост-серверов VMware ESXi:

После того, как вы назначите виртуальной машине метку с данной политикой, начнется процесс контроля целостности (проверка каждые 10 минут). Будет производиться сравнение эталонной контрольной суммы ВМ с текущей. При несовпадении контрольных сумм ВМ фиксируется нарушение целостности и изменяется статус ВМ, которых может быть несколько.

Однако надо помнить, что нужно защищать также и сами хост-серверы ESXi, находящиеся в датацентре компании. Для эффективной защиты сервера виртуализации, помимо vGate R2, необходим электронный замок - ПАК «Соболь» версии 3.0 для реализации следующих защитных механизмов:

• идентификация и аутентификация пользователей на входе в систему (непосредственно при запуске сервера);
• ведение журнала безопасности;
• сигнализация попыток нарушения защиты;
• запрет загрузки с внешних носителей;
• контроль конфигурации (PCI-устройств, ACPI, SMBIOS и оперативной памяти).

Весь перечисленный комплекс возможностей не позволит злоумышленнику (в случае если он получил физический доступ к серверу виртуализации) реализовать одну из наиболее распространенных угроз – перезагрузку сервера и загрузку с внешнего носителя для получения доступа ко всей информации, хранящейся на сервере.

Так как, во-первых, злоумышленник столкнется с необходимостью идентификации/аутентификации до старта операционной системы, при этом реализованный механизм защиты от подбора паролей после трех неудачных попыток заблокирует сервер. Во-вторых, если злоумышленник, имея в распоряжении идентификационные данные, пройдет «первый барьер защиты», то на «втором» его будет ждать блокировка всех внешних устройств (CD-ROM, USB, eSata и т.д.), что исключает возможность загрузки нештатной ОС с любых внешних носителей.

Единственной недоступной возможностью при использовании ПАК «Соболь» версии 3.0 на сервере виртуализации, работающем под управлением VMware vSphere 5, является контроль целостности (КЦ) программной среды до загрузки ОС.

В руководящем документе ФСТЭК России нет разделения на КЦ в операционной системе или до ее старта, поэтому при использовании «тандема» vGate R2 и ПАК «Соболь» версии 3.0 требование 4.1. «Обеспечение целостности программных средств и обрабатываемой информации» будет выполнено средствами vGate R2.

Таким образом, применение обоих средств защиты информации – ПАК «Соболь» версии 3.0 и vGate R2 – в комплексе позволяет защитить сервер с установленной платформой для виртуализации VMware vSphere 5 и нейтрализовать угрозы непосредственного доступа (угрозы, реализуемые до загрузки ОС, и угрозы, реализуемые после загрузки ОС).

Наличие у продуктов сертификатов ФСТЭК России позволяет использовать vGate R2 и ПАК «Соболь» версии 3.0 для защиты информации, составляющей коммерческую или государственную тайну в автоматизированных системах с классом защищенности до 1Б включительно.

Напомним, что версия vGate R2 с поддержкой vSphere 5 уже поступила в продажу, а бесплатную пробную версию продукта можно скачать тут.

Как известно, виртуализация требует дополнительных ресурсов сверх тех, которые потребляет непосредственно виртуальная машина. Это называют накладными расходами на виртуализацию (так называемый virtualization overhead). Оверхэд есть как для процессора (примерно 3-5 процентов на хост-сервере), так и для оперативной памяти.

При этом для оперативной памяти накладные расходы гипервизора зависят от количества виртуальных процессоров (vCPU) и объема оперативной памяти, выделенных виртуальной машине. Мы уже писали о накладных расходах по RAM для виртуальных машин в VMware vSphere 4, где использовались следующие средние значения:

Информация эта взята из vSphere 4.0 Online Library.

В VMware vSphere 5 есть новая возможность, которая называется VMX Swap. При включении виртуальной машины гипервизор ESXi создает для нее vmx-процесс, управляющий различными структурами данных, под которые требуется физическая оперативная память. Ее объем, как было сказано, зависит от конфигурации ВМ - количества vCPU и RAM. Для снижения потребления этой памяти в ESXi 5.0 механизм VMX Swap создает swap-файл для сегментов данных процесса vmx, куда сбрасываются страницы памяти, но только в случае нехватки физической оперативной памяти на хосте.

VMX Swap создает файлы подкачки в директории с виртуальной машиной, через который и происходит загрузка и выгрузка страниц процесса vmx. Размещение этих файлов можно переопределить, добавив следующий параметр в расширенные настройки виртуальной машины:

sched.swap.vmxSwapDir

По умолчанию механизм VMX Swap включен и в критических ситуациях позволяет уменьшить overhead типичной виртуальной машины с 50 МБ до 10 МБ. Для виртуализации серверов такие порядки цифр может и не очень важны, зато для виртуализации настольных ПК (например, VMware View), где на одном сервере могут находиться десятки и даже сотни виртуальных машин, эта возможность может оказаться весьма кстати в условиях нехватки вычислительных ресурсов.

Если вы считаете, что ресурсов у вас достаточно и VMX Swap вам не нужен, можно его отключить, добавив значение FALSE в следующу расширенную настройку виртуальной машины:

sched.swap.vmxSwapEnabled

Ну а теперь посмотрим сколько оверхэда по памяти потребляет виртуальная машина уже в VMware vSphere 5 с включенным по умолчанию VMX Swap:

Эта информация уже из vSphere 5 Documentation Center. Как мы видим из таблицы, накладные расходы по памяти с учетом VMX Swap уже значительно меньше (в некоторых случаях до 8-9 раз). Как уверяют коллеги из VMware, в условиях недостатка ресурсов VMX Swap почти не влияет на производительность хост-сервера ESXi, ну а в условиях достатка - не влияет совсем.

В последнее время стало модным предоставлять виртуальные машины в аренду по модели IaaS. Этим занимается VMware со своей платформой vCloud в корпоративных инфраструктурах, а также Amazon, Microsoft и Google - в публичных облаках. Программы для облачных провайдеров есть также и поставщиков сопутствующих продуктов в сфере виртуализации, например, у Veeam и Кода Безопасности.

Теперь и компания StarWind позволяет провайдерам услуг использовать в датацентрах свои продукты StarWind iSCSI SAN и StarWind Native SAN for Hyper-V (статьи о продуктах тут и тут).

Напомним, что продукты StarWind позволяют создавать отказоустойчивые конфигурации хранилищ на базе iSCSI для виртуальных машин VMware vSphere, Microsoft Hyper-V и Citrix XenServer. При этом не требуется инвестиций в дорогостоящие хранилища Fibre Channel и сетевую инфраструктуру SAN, что делает продукты StarWind наиболее эффективными с точки зрения стоимости владения и единовременных капитальных затрат на создание инфраструктуры датацентра.

Кроме того, StarWind это:

• Динамическое масштабирование хранилищ "на лету"
• Отказоустойчивая конфигурация из двух или трех узлов кластера хранилищ
• Использование существующих серверов и хранилищ данных
• Простое администрирование решения
• Встроенные механизмы дедупликации и резервного копирования виртуальных машин

Тем, кого заинтересовала программа IaaS у компании StarWind, необходимо обратиться по адресу sales@starwindsoftware.com.

На сайте Фрэнка Деннемана появилась отличная статья про механизмы "горячей" миграции хранилищ (Storage vMotion) и "горячей" миграции виртуальных машин (vMotion) в контексте их использования для одного хранилища (Datastore) или хоста ESXi в VMware vSphere. Мы просто не можем не перевести ее, так как она представляет большой интерес для понимания работы этих механизмов.

Начнем со Storage vMotion. Данная операция, очевидно, требует большой нагрузки как на хранилище, откуда и куда, переносятся виртуальные машины, так и на сам хост-сервер VMware ESXi. Особенно актуально это, когда хост или хранилище переходят в Maintenance Mode, и виртуальные машины массово начинают миграцию. В случае со Storage vMotion это создает колоссальную нагрузку на хранилище по вводу-выводу.

Для понимания затрат ресурсов на эти процессы Фрэнк вводит понятие "цены" (cost) начинающейся операции, которая не может превосходить количество доступных слотов на хосте или хранилище, выделенных под них. Наглядно это можно представить так:

Resource Max Cost - это максимальный объем в неких единицах (назовем их слотами), который находится в рамках пула доступных ресурсов для операции Storage vMotion. Для хоста ESXi емкость такого пула составляет 8 слотов, а цена операции Storage vMotion - 4 слота. Таким образом, на одном хосте ESXi могут одновременно выполняться не более 2-х операций Storage vMotion. Если выполняется одна операция - то занято 4 слота и 4 слота свободно (как для исходного, так и для целевого хранилища).

С хранилищем точно такая же система - но у него 128 слотов. Одна операция Storage vMotion для Datastore потребляет 16 слотов. Таким образом, на одном хранилище может выполняться 8 (128 / 16) одновременных операций Storage vMotion. Их могут инициировать, например, 4 хоста (по 2 операции максимально каждый). То есть, мы получаем следующую схему:

Все просто и понятно. Отметим здесь, что операция vMotion тоже потребляет ресурсы с Datastore - но всего 1 слот. Таким образом, на одном Datastore могут, например, выполняться 7 одновременных миграций Storage vMotion (7 * 16 = 112 слотов) и еще 16 миграций vMotion (112+16 = 128), задействующих ВМ этого Datastore.

Если вы не хотите, чтобы при переводе Datastore в Maintenance Mode на нем возникало сразу 8 одновременных миграций Storage vMotion и, как следствие, большой нагрузки, вы можете уменьшить пул слотов для хранилищ (для всех, а не для какого-то конкретно). Для этого нужно отредактировать конфигурационный файл vpxd.cfg на сервере VMware vCenter, который находится в папке:

%ALLUSERPROFILE%\Application Data\VMware\VMware VirtualCenter\

Там нужно вписать новое значение в следующую секцию, где "new value":

< config >
< vpxd >
< ResourceManager >
< MaxCostPerEsx41DS > new value < /MaxCostPerEsx41DS >
< /ResourceManager >
< /vpxd >
< /config >

Вбив значение 112, вы уменьшите максимальное число одновременных миграций Storage vMotion на Datastore до 7. На хосте ESXi менять размер пула слотов для Storage vMotion не рекомендуется (хотя такие секции можно добавить - это пробовали энтузиасты).

Про стоимость миграций vMotion для хостов ESX / ESXi 4.1 мы уже писали вот тут. На эту тему есть также статья KB 2001417. С тех пор в vMotion много чего изменилось, поэтому подтвердить актуальность для vSphere 5 пока не могу. Буду признателен, если вы напишете об этом в комментариях.

У Михаила Козлова, бизнес-эксперта по защите информации с помощью решений компании Код Безопасности, появилась интересная презентация на Slideshare - "Бизнес-кейс: защита Персональных Данных при помощи решений компании "Код Безопасности":

Используя собственную методику расчета репутационных потерь компании (для примера взята достаточно большая публичная компания), возникших вследствие утечки 100 000 записей с персональными данными клиентов (ПДн), Михаил оценивает максимально возможную стоимость репутационных потерь (из-за оттока клиентов и упущенной прибыли). Несмотря на то, что в методике некоторые показатели взяты эмпирически, выглядит она достаточно убедительной.

Основная идея презентации - если потеря ПДн приведет к оттоку клиентов и репутационным потерям, то необходимо использовать соответствующие решения по защите ПДн, которые обойдутся значительно дешевле суммы возможных финансовых потерь.

В этой связи, конечно же, не можем не отметить решения компании Код Безопасности, которые предназначены для защиты персональных данных, а именно продукт vGate R2, который защищает ПДн, обрабатывающиеся в виртуальных машинах на платформах VMware vSphere. Делается это средствами политик, с помощью которых происходит автоматическая настройка безопаной конфигурации хостов и виртуальных машин в соответствии со стандартами и лучшими практиками, а также за счет встроенных механизмов защиты от несанкционированного доступа. vGate R2 имеет все необходимые сертификаты ФСТЭК (включая сертификаты на vSphere 5.0).

Также на тему защиты ПДн в виртуальных инфраструктурах рекомендуем прочесть следующие наши заметки:

• Защита персональных данных, обрабатываемых в виртуальной инфраструктуре VMware vSphere, с помощью vGate R2
• Защита персональных данных при использовании технологий виртуализации в банках с помощью vGate R2
• Статьи о продукте vGate R2 от Кода Безопасности - защита персональных данных и соответствие требованиям PCI DSS

Что еще вы можете почитать на тему защиты ПДн в виртуальной инфраструктуре с помощью vGate R2 (документы Кода Безопасности):

• Выполнение требований законодательства по защите информации государственными компаниями при использовании технологий виртуализации
• Перенос информационных систем персональных данных в виртуальную инфраструктуру
• Выполнение требований СТО БР ИББС в части защиты персональных данных при использовании технологий виртуализации

Ну и, в довершение, презентация о ПДн и vGate R2:

Напомним, что версия vGate R2 с поддержкой vSphere 5 уже поступила в продажу, а бесплатную пробную версию продукта можно скачать тут.

В первой части статьи о продукте vGate R2, предназначенном для защиты виртуальной инфраструктуры VMware vSphere, мы рассмотрели механизмы того, как с помощью него можно защитить инфраструктуру сервис-провайдера от внешних уроз в сфере информационной безопасности. В этой части статьи мы рассмотрим не менее важный аспект защиты инфраструктуры виртуализации - защиту от внутренних (инсайдерских) угроз в датацентрах средствами сертифицированного ФСТЭК решения vGate R2.

В середине марта этого года компания VMware выпустила технологическое превью продукта VMware Workstation 2012, в котором впервые была анонсирована возомжность WSX - доступ к консоли виртуальной машины через браузер, в том числе, и с мобильных устройств, таких как Apple iPad под управлением iOS 5 и выше. На днях обновился это технологический релиз (VMware Workstation 2012 TP June), в котором появилось несколько интересных возможностей.

Напомним, что WSX Server, который есть в Workstation 2012, работает на базе технологии HTML 5 (с поддержкой WebSockets), что подразумевает отсутствие необходимости иметь какие-либо дополнительные компоненты, кроме веб-браузера, чтобы получить доступ к консоли виртуальной машины и средствами управления ей. В качестве веб-браузеров, той или иной степени совместимых с HTML 5, можно использовать Chrome 17, Firefox 10, IE 10, Safari 5 на ПК с Mac OS и iOS 5 для iPad. Отметим также, что эта возможность на данном этапе является "очень экспериментальной" (например, известно, что картинка иногда "зависает" и нужно повторно переподключиться).

В частности, все неплохо работает на New iPad с экраном Retina:

Добавим также, что компонент WSX Server есть как под Windows, так и под Linux, и доступен для загрузки вместе с основным дистрибутивом продукта.

Среди новых возможностей VMware Workstation 2012 TP June:

• Поддержка гостевых и хостовых ОС Windows 8 и Windows Server 2012
  
• Поддержка Ubuntu 12.04
• Улучшения движка графического рендеринга и общие улучшения производительности
  
• Поддержка OpenGL для гостевых ОС Linux
  
• Restricted Virtual Machines - возможность задать дополнительный пароль для зашифрованных ВМ, чтобы предотвратить изменение их конфигурации со стороны неавторизованных пользователей (например, ВМ для студентов)
• Возможность загрузки виртуальных машин на хосты VMware vSphere и обратно с них на Workstation
• Возможность запуска "вложенных" виртуальных машин с ESX/ESXi
  
• Запуска сервера Hyper-V в качестве гостевой ОС (эта возможность официально не поддерживается и никогда не будет)
• Счетчики производительности виртуальных машин для профилирования приложений из гостевой ОС
• Remote connections - существенные улучшения производительности при соединении с консолью ВМ на VMware vSphere или к машинам Workstation с помощью VNC-клиента
• Disk Cleanup - новая возможность почистить место в папке с файлами виртуальной машины
• UI Changes - интерфейс стал более современным и удобным
• Существенно доработан сервер WSX, о котором написано выше
• Поддержка голосового движка через WSX на Mac OS и iOS при работе с консолью ВМ Windows

Более подробно о VMware Workstation 2012 TP June можно прочитать на странице ведущего разработчика, а также на официальной странице обновленного продукта. Скачать VMware Workstation 2012 TP June вместе с компонентами WSX можно по этой ссылке.

Также обновился технологический релиз продукта VMware Fusion 2012 TP June. Новые возможности Fusion 2012:

• Поддержка Windows 8 в виртуальных машинах, а также возможность импорта физических ПК в ВМ
• Установлка в режиме "Boot Camp"
• Улучшенная стабильность при работе с приложениями для Windows 7 и Windows 8
• Запуск приложений Windows 7 и Windows 8 в режиме Unity
• Поддержка ВМ с гостевой ОС Linux и 3D desktops, включая Ubuntu 12.04 LTS и последние релизы OpenSUSE
• Улушчение производительности и надежности операций suspend, resume, pause, restart
• Импорт машин в OVF-формате
• Новый прототип библиотеки виртуальных машин (virtual machine library)
• Новый механизм работы с окнами VMware Fusion (настройки, снапшоты и т.п.)

Скачать VMware Fusion 2012 TP June можно по этой ссылке, дополнительная информация о новых возможностях доступна тут.

На блогах компании Gartner появился очередной "магический квандрант", описывающий состояние дел на рынке платформ виртуализации x86-архитектуры по состоянию на июнь 2012 года:

Напомним, что магический квадрант Gartner используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:

• Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
• Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
• Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
• Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.

В этой же публикации рассматриваются сильные и слабые стороны вендоров рынка виртуализации, таких как VMware, Citrix, Microsoft, Oracle, Parallels и Red Hat. В исследовании анализировались аспекты платформ виртуализации (серверных, а также "контейнеров" - виртуализации уровня ОС от Parallels) в связке с простейшими функциями по администрированию виртуальной инфраструктуры (высокоуровневые задачи не рассматривались).

Для тех, кому интересно сравнение с прошлым годом, наши коллеги сделали хорошую гифку:

По этой гифке хорошо видно, что компания Citrix сдала позиции в плане законченности и ясности своей стратегии развития продуктов (в частности, XenServer), а Microsoft приблизилась к VMware в обоих аспектах: как в плане заявленной стратегии, так и в плане ее реализации. Очевидно, что произошло это благодаря существенной доработке серверной платформы Microsoft Windows Server 2012 и новому поколению гипервизора Hyper-V 3.0, который в некоторых вещах даже превосходит VMware vSphere.

К сильным сторонам VMware компания Gartner отнесла продуманную стратегию развития продуктов, технологическое лидерство и инновации, высокий уровень удовлетворенности пользователей продуктами, а также очень обширную базу инсталляций и увеличившееся число провайдеров облачных услуг (VSPP). Сильными сторонами Microsoft Gartner признает существующую экосистему Windows-инфраструктур, большое количество пользователей и администраторов Windows-based систем (особенно крупных компаний Windows-only), невысокие цены при неплохой функциональности для компаний среднего размера, а также финансовую состоятельность самой корпорации (а значит и хорошие маркетинговые ресурсы).

К слабым сторонам Oracle отнесена их сфокусированность на рынке своих же продуктов, Citrix не очень понятно разивает свое партнерство с Microsoft в сегменте серверной виртуализации, Parallels не очень хвалят за архитектуру решения, а Red Hat ругают за плохой маркетинг и небольшую экосистему.

Ну а про то, как обстояли дела в 2010 году, написано у нас тут.

Оказывается у компании StarWind Software, выпускающей продукт №1 StarWind iSCSI SAN для создания отказоустойчивых хранилищ под VMware vSphere и Microsoft Hyper-V, среди прочих бесплатных утилит, есть продукт StarWind Tape Redirector.

Этот продукт пригодится вам тогда, когда вы перенесли виртуальную машину в среду Microsoft Hyper-V, при этом для самой ВМ требуется резервное копирование файлов гостевой ОС напрямую на ленту. Как известно средствами гипервизора пробросить ленточную библиотеку в виртуальную машину не получится, поэтому можно в Parent Partition сервера Hyper-V поставить StarWind Tape Redirector и уже с самого родительского раздела отправлять резервные копии (например, Symantec Backup Exec 2012) на ленты по протоколам Fibre Channel, SAS или SCSI.

После установки продукта, в консоли StarWind Management Console у вас появится пошаговый мастер, с помощью которого можно настроить такую схему резервного копирования.

Скачать StarWind Tape Redirector можно по этой ссылке.

Как мы уже писали в одной из статей, в VMware vSphere 5 при работе виртуальных машин с хранилищами могут возникать 2 похожих по признакам ситуации:

APD (All Paths Down) - когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. При этом хост не знает, в течение какого времени будет сохраняться такая ситуация. Типичный пример - отказ FC-коммутаторов в фабрике или выход из строя устройства хранения. В этом случае хост ESXi будет периодически пытаться обратиться к устройству (команды чтения параметров диска) через демон hostd и восстановить пути. В этом случае демон hostd будет постоянно блокироваться, что будет негативно влиять на производительность. Этот статус считается временным, так как устройство хранения или фабрика могут снова начать работать, и работа с устройством возобновится.

В логе /var/log/vmkernel.log ситуация APD выглядит подобным образом:

2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_IssueCommandToDevice:2954:I/O could not be issued to device "naa.60a98000572d54724a34642d71325763" due to Not found
2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_DeviceRetryCommand:133:Device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update for failover with I/O blocked. No prior reservation exists on the device.
2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.60a98000572d54724a34642d71325763" is blocked. Not starting I/O from device.
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.60a98000572d54724a34642d71325763" - issuing command 0x4124007ba7c0
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.60a98000572d54724a34642d71325763" - failed to issue command due to Not found (APD), try again...
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update...
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.60a98000572d54724a34642d71325763" - issuing command 0x4124007ba7c0
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.60a98000572d54724a34642d71325763" - failed to issue command due to Not found (APD), try again...
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update...

Ключевые слова здесь: retry, awaiting. Когда вы перезапустите management agents, то получите такую вот ошибку:

Not all VMFS volumes were updated; the error encountered was 'No connection'.
Errors:
Rescan complete, however some dead paths were not removed because they were in use by the system. Please use the 'storage core device world list' command to see the VMkernel worlds still using these paths.
Error while scanning interfaces, unable to continue. Error was Not all VMFS volumes were updated; the error encountered was 'No connection'.

В этом случае надо искать проблему в фабрике SAN или на массиве.

PDL (Permanent Device Loss) - когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось. Определяется это, в частности, по коду ответа для SCSI-команд, например, вот такому: 5h / ASC=25h / ASCQ=0 (ILLEGAL REQUEST / LOGICAL UNIT NOT SUPPORTED) - то есть такого устройства на массиве больше нет (понятно, что в случае APD по причине свича мы такого ответа не получим). Этот статус считается постоянным, так как массив ответил, что устройства больше нет.

А вообще есть вот такая табличка для SCSI sense codes, которые вызывают PDL:

В случае статуса PDL гипервизор в ответ на запрос I/O от виртуальной машины выдает ответ VMK_PERM_DEV_LOSS и не блокирует демон hostd, что, соответственно, не влияет на производительность. Отметим, что как в случае APD, так и в случае PDL, виртуальная машина не знает, что там произошло с хранилищем, и продолжает пытаться выполнять команды ввода-вывода.

Такое разделение статусов в vSphere 5 позволило решить множество проблем, например, в случае PDL хост-серверу больше не нужно постоянно пытаться восстановить пути, а пользователь может удалить сломавшееся устройство с помощью операций detach и unmount в интерфейсе vSphere Client (в случае так называемого "Unplanned PDL"):

В логе /var/log/vmkernel.log ситуация PDL (в случае Unplanned PDL) выглядит подобным образом:

2011-08-09T10:43:26.857Z cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba3:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.857Z cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba4:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.857Z cpu2:853571)WARNING: vmw_psp_rr: psp_rrSelectPathToActivate:972:Could not select path for device "naa.60a98000572d54724a34642d71325763".
2011-08-09T10:43:26.857Z cpu2:853571)WARNING: ScsiDevice: 1223: Device :naa.60a98000572d54724a34642d71325763 has been removed or is permanently inaccessible.
2011-08-09T10:43:26.857Z cpu3:2132)ScsiDeviceIO: 2288: Cmd(0x4124403c1fc0) 0x9e, CmdSN 0xec86 to dev "naa.60a98000572d54724a34642d71325763" failed H:0x8 D:0x0 P:0x0
2011-08-09T10:43:26.858Z cpu3:2132)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.60a98000572d54724a34642d71325763" is blocked. Not starting I/O from device.
2011-08-09T10:43:26.858Z cpu2:2127)ScsiDeviceIO: 2316: Cmd(0x4124403c1fc0) 0x25, CmdSN 0xecab to dev "naa.60a98000572d54724a34642d71325763" failed H:0x1 D:0x0 P:0x0 Possible sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.858Z cpu2:854568)WARNING: ScsiDeviceIO: 7330: READ CAPACITY on device "naa.60a98000572d54724a34642d71325763" from Plugin "NMP" failed. I/O error
2011-08-09T10:43:26.858Z cpu2:854568)ScsiDevice: 1238: Permanently inaccessible device :naa.60a98000572d54724a34642d71325763 has no more open connections. It is now safe to unmount datastores (if any) and delete the device.
2011-08-09T10:43:26.859Z cpu3:854577)WARNING: NMP: nmpDeviceAttemptFailover:562:Retry world restore device "naa.60a98000572d54724a34642d71325763" - no more commands to retry

Ключевое слово здесь - permanently.

Становится понятно, что в случае, когда устройство хранения (LUN) реально сломалось или удалено сознательно, лучше всего избежать ситуации APD и попасть в статус PDL. Сделать это удается хост-серверу ESXi не всегда - по прежнему в vSphere 5.0 Update 1 это обрабатывается в ограниченном количестве случаев, но в vSphere 5.1 обещают существенно доработать этот механизм.

Также есть Advanced Settings на хосте ESXi, которые позволяют управлять дальнейшей судьбой машины, которая оказалась жертвой ситуации PDL. В частности есть 2 следующие расширенные настройки (начиная с vSphere 5.0 Update 1) - первая в категории "Disk", а вторая в расширенных настройках кластера HA:

disk.terminateVMonPDLDefault - если эта настройка включена (True), то в ситуации PDL для устройства, где находится ВМ, эта машина будет выключена. Настройка задается на уровне хоста ESXi и требует его перезагрузки для ее применения.

das.maskCleanShutdownEnabled - это настройка, будучи включенной (True), позволяет механизму VMware HA приступить к восстановлению виртуальной машины. Соответственно, если она выключена, то HA проигнорирует выключение виртуальной машины в случае ее "убийства" при включенной первой настройке.

Рекомендуется, чтобы обе эти настройки были включены.

Все описанные выше механизмы могут очень пригодиться при построении и обработке сбоев в "растянутых кластерах" VMware HA, построенных между географически разнесенными датацентрами. Об этом всем детально написано в документе "VMware vSphere Metro Storage Cluster Case Study".

После недавнего выпуска обновленной версии своих рекомендаций по обеспечению информационной безопасности VMware vSphere 5 Security Hardening, компания VMware обновила и свою бесплатную утилиту для проверки на соответствие данным требованиям - vSphere 5.0 Compliance Checker.

Основные особенности нового релиза vSphere 5.0 Compliance Checker:

• Сканирование конфигураций хост-серверов на безопасность идет для 5 хостов одновременно (на одном vCenter)
• Обследование строится на базе практик Hardening Guidelines, которые являются частью контента vCenter Configuration Manager (vCM)
• Результат представляет собой таблицу соответствия (или несоответствия) пунктам Security Hardening с детальным описанием каждого пункта

Пример вывода vSphere 5.0 Compliance Checker:

Следующим релизом компания VMware обещает выпустить сканер на соответствие требованиям HIPAA.

Напомним, что после того, как вы с помощью данного сканера поняли, что нужно настроить хост-серверы в соответствие с лучшими практиками ИБ в виртуальных средах, необходимо воспользоваться продуктом vGate R2, который делает это не только на базе зарубежных наборов политик, но и отраслевых российских стандартов, таких как, например, требования Банка России.

В конце прошлой недели компания VMware в рамках проекта Labs выпустила очень интересный продукт - VMware ThinApp Factory, который предоставляется бесплатно всем пользователям с действующей лицензией на VMware ThinApp (входит в издание VMware View Premier). ThinApp Factory позволяет производить масштабное создание виртуализованных приложений в контейнерах ThinApp в корпоративных окружениях, насчитывающих сотни приложений, из единой консоли. С помощью ThinApp Factory массовая упаковка приложений в контейнеры превращается в упорядоченный рабочий процесс, приводящий в итоге к публикации приложений в сервисе федерации VMware Horizon Application Manager (на картинке он еще называется ThinApp Store):

VMware ThinApp Factory поставляется в виде виртуального модуля (Virtual Appliance), построенного на базе ОС Debian Linux с веб-интерфейсом управления на базе сервера TomCat. В качестве источников для создания виртуализованных приложений могут быть использованы файловые хранилища с инсталляторами приложений, импортированные вручную дистрибутивы, а также источники "RSS-style app-installer feeds" в формате JSON (JavaScript Object Notation).

Упаковка приложений производится в потоковом режиме с одновременным исполнением нескольких задач:

Используя источники приложений в формате JSON, можно отслеживать появление новых версий приложения и тут же паковать их:

Приложения автоматически скачиваются из источников, указанных администратором, и складываются в репозиторий:

VMware ThinApp Factory имеет также возможность "рецептов" (Recipes) - наборов шагов настройки приложений (они берутся из уже установленных приложений или пакетов ThinApp), которые сохраняются в базе и могут быть применены к создаваемым пакетам виртуализованных приложений. Источником рецепта может быть пользователь или рекомендации VMware.

Само собой, поддерживается и импорт существующих проектов ThinApp:

В ThinApp Factory можно создать Virtual Machine Work Pool - пул виртуальных машин, в которых будет происходить создание виртуализованных приложений, в соответствии с их требованиями к версии операционной системы (напомним о необходимости наличий лицензий для них):

Наряду с функциями автоматического создания пакетов, в ThinApp Factiry администратор может самостоятельно "записывать" проект и создавать пакет:

Для работы виртуального модуля ThinApp Factory потребуется серверная платформа VMware vSphere 4.1 или более поздней версии, либо настольная платформа VMware Workstation 8.x или более поздняя. На тему функциональности и архитектуры ThinApp Factory есть также неплохая презентация.

Основная страница продукта VMware ThinApp Factory находится тут, документация доступна по этой ссылке.

Продолжаем вас знакомить с продуктом номер 1 - vGate R2, предназначенным для защиты виртуальных сред VMware vSphere. Напомним, что он позволяет производить автоматическую настройку конфигурации безопасности хост-серверов VMware ESX / ESXi средствами политик, защищать инфраструктуру от несанционированного доступа, а также имеет все необходимые сертификаты ФСТЭК (включая сертификаты на vSphere 5.0).

Не так давно мы уже писали о том, что в целях обеспечения отказоустойчивости в инфраструктуре vGate R2 можно сделать резервный сервер авторизации, который возьмет на себя функции решения в случае отказа основного сервера. Однако, помимо традиционной отказоустойчивости, полезно делать резервное копирование конфигурации, например, на случай ее случайной порчи или совершения некорректных настроек. Также резервное копирование конфигурации сервера авторизации надо обязательно делать перед обновлением продукта на новую версию, чтобы в случае чего не настраивать все параметры защиты заново.

Для этого в vGate R2 есть специальная утилита db-util, которая находится на установочном диске в каталоге \Tools. Сделать резервную копию конфигурации сервера авторизации можно простой командой:

D:\vGate\Tools\db-util.exe -b c:\Backup

После этого нужно убедиться, что в указанном целевом каталоге присутствуют файлы резервной копии. При необходимости восстановления можно воспользоваться командой:

D:\vGate\Tools\db-util.exe -r c:\Backup

Помните, что предварительно нужно остановить все службы vGate, иначе восстановиться не получится. При необходимости вы также можете использовать следующие аргументы:

• -f [--force] – команда восстановления конфигурации -r [--restore] не будет запрашивать подтверждение на операцию;
• -v [--verbose] – операции резервирования и восстановления будут иметь подробный вывод (лучше этот ключ указать).

Если по каким-либо причинам восстановить конфигурацию vGate R2 не получилось, нужно полностью удалить продукт и PosgreSQL с сервера авторизации, затем поставить его заново и восстановить конфигурацию.

Напомним, что версия vGate R2 с поддержкой vSphere 5 уже поступила в продажу, а бесплатную пробную версию продукта можно скачать тут.

Не все знают, что в качестве распределенного коммутатора с расширенной функциональностью для инфраструктуры VMware vSphere существует не только устройство Cisco Nexus 1000V. Есть также и виртуальное устройство от IBM, которое называется System Networking Distributed Switch 5000V (DVS 5000V).

Это тоже программный распределенный коммутатор, который поставляется в виде 2 компонентов:

• Host Module (он же Data Path Module, DPM) - модуль, поставляемый в zip-формате (Offline Bundle) для хостов VMware ESXi 5.x, позволяющий контролировать состояние виртуальных коммутаторов в пределах хоста.
• Controller - виртуальный модуль (Virtual Appliance) в формате OVA, позволяющий централизованно управлять сетевой инфраструктурой виртуализации через хостовые модули.

vDS от IBM так же, как и Nexus 1000V, интегрирован с VMware vCenter и отображается как обычный Distributed Virtual Switch в интерфейсе vSphere Client. При этом он обладает следующими расширенными возможностями:

• Поддержка технологии Private VLAN для разделения трафика ВМ
• Поддержка списков контроля доступа (ACL) для контроля трафика ВМ
• Поддержка технологий зеркалирования портов (Port Mirroring): локально (SPAN) и удаленной (ERSPAN)
• Поддержка техники мониторинга трафика sFlow (похожа на NetFlow)
• Управление трафиком и статистика на базе стандарта IEEE 802.1Qbg (Edge Virtual Bridging, EVB)
• Поддержка технологий Static Port Aggregation и Dynamic Port Aggregation
• Поддержка логирования Syslog и по SNMP

С точки зрения управления таким распределенным коммутатором DVS 5000V оно построено на базе операционной системы IBM NOS (Network Operating System) и предоставляет следующие интерфейсы:

• Telnet
• SSH
• SNMP
• TACACS+
• RADIUS
• Интерфейс командной строки (CLI)

Более подробно о виртуальном модуле IBM DVS 5000V можно прочитать в даташите, а также в руководстве пользователя.

Компания StarWind, выпускающая продукт номер 1 для создания отказоустойчивых iSCSI-хранилищ серверов VMware vSphere и Microsoft Hyper-V, опять объявила о бесплатной раздаче NFS-лицензий на StarWind iSCSI SAN и StarWind Native SAN for Hyper-V для определенных групп ИТ-профессионалов. В их число входят:

• VMware vExpert
• VMware Certified Instructor (VCI)
• Microsoft Most Valuable Professional (MVP)
• Microsoft Certified Trainer (MCT)
• Citrix Technology Professional (CTP)
• Citrix Certified Instructor (CCI)

Тут вы можете прочитать о возможностях новой версии StarWind iSCSI SAN 5.9. А получить бесплатные NFR-лицензии можно по этой ссылке: http://www.go.starwindsoftware.com/free-nfr-license, либо написав письмо по адресу: roman.shovkun@starwindsoftware.com. Сделать это можно до 30 сентября 2012 года.

Традиционно, бесплатные лицензии раздаются только для непроизводственного использования, т.е. только для целей тестирования, обучения, демонстраций и т.п. Ну и напомним, что если вы не принадлежите к данным группам ИТ-профессионалов, вы всегда можете скачать бесплатную версию StarWind iSCSI SAN Free, где есть следующие возможности:

• Дедупликация блоков виртуальных дисков
• Техники защиты данных: CDP и снапшоты
• Thin Provisioning (диски, растущие по мере наполнения их данными)
• Высокопроизводительное кэширование

Для обладателей устройств iPad или iPhone и, по совместительству, разработчиков сценариев для автоматизации операций в виртуальной инфраструктуре VMware vSphere на App Store есть замечательное справочное руководство по скриптам PowerCLI - vPowerCLI5 Reference.

Справочник включает в себя более 200 командлетов PowerCLI, которые упорядочены в алфавитном порядке, также есть поиск. Для каждого командлета предоставляется описание, взятое из vSphere PowerCLI Reference от VMware.

Обращаем также внимание на плакаты PowerCLI для ESXi Image Builder и Auto Deploy в формате PDF.

Мы уже писали об облачной платформе  Amazon Web Services (AWS), куда включен продукт Amazon Elastic Compute Cloud (EC2) - один из самых известных сервисов IaaS по аренде ресурсов для виртуальных машин. Недавно компания Amazon объявила, что теперь есть не только возможность импорта виртуальных машин на платформах вендоров VMware, Citrix и Microsoft, но и обратный их экспорт в частное облако клиента в соответствующих форматах. Несмотря на то, что технически сделать это весьма просто, компания затягивала с этой возможностью.

Напомним, что импорт виртуальной машины, например с VMware vSphere, можно сделать средствами Amazon EC2 VM Import Connector for VMware vCenter, который является плагином к vSphere Client:

Экспорт инстанса делается средствами командной строки с помощью задачи ec2-create-instance-export-task. Например, в формат VMware можно экспортировать следующим образом:

ec2-create-instance-export-task –e vmware -b NAME-OF-S3-BUCKET INSTANCE-ID

Для экспорта потребуется ID инстанса, имя хранилища (S3 Bucket) и тип выходного образа (vmware, citrix или microsoft).

Мониторинг процесса экспорта выполняется командой ec2-describe-export-tasks, а отмена экспорта - ec2-cancel-export-task. Полный синтаксис операций экспорта экземпляров EC2 в виртуальные машины частного облака можно изучить по этой ссылке.

Мы уже недавно писали о метриках производительности хранилищ в среде VMware vSphere, которые можно получить с помощью команды esxtop. Сегодня мы продолжим развивать эту тему и поговорим об общей производительности дисковых устройств и сайзинге нагрузок виртуальных машин по хранилищам в виртуальной среде.

Как говорит нам вторая статья блога VMware о хранилищах, есть несколько причин, по которым может падать производительность подсистемы ввода-вывода виртуальных машин:

• Неправильный сайзинг хранилищ для задач ВМ, вследствие чего хранилища не выдерживают такого количества операций, и все начинает тормозить. Это самый частый случай.
• Перегрузка очереди ввода-вывода со стороны хост-сервера.
• Достижение предела полосы пропускания между хостом и хранилищем.
• Высокая загрузка CPU хост-сервера.
• Проблемы с драйверами хранилищ на уровне гостевой ОС.
• Некорректно настроенные приложения.

Из всего этого набора причин самой актуальной оказывается, как правило, первая. Это происходит вследствие того, что администраторы очень часто делают сайзинг хранилищ для задач в ВМ, учитывая их требования только к занимаемому пространству, но не учитывая реальных требований систем к вводу выводу. Это верно в Enterprise-среде, когда у вас есть хранилища вроде HDS VSP с практически "несъедаемой" производительностью, но неверно для Low и Midrange массивов в небольших организациях.

Поэтому профилирование нагрузки по хранилищам - одна из основных задач администраторов VMware vSphere. Здесь VMware предлагает описывать модель нагрузки прикладной системы следующими параметрами:

• Размер запроса ввода-вывода (I/O Size)
• Процент обращений на чтение (Read)
• Процент случайных обращений (Random)

Таким образом профиль приложения для "типичной" нагрузки может выглядеть наподобие:

8KB I/O size, 80% Random, 80% Read

Само собой, для каждого приложения типа Exchange или СУБД может быть свой профиль нагрузки, отличающийся от типичного. Размер запроса ввода-вывода (I/O Size) также зависит от специфики приложения, и о том, как регулировать его максимальное значение на уровне гипервизора ESXi, рассказано в KB 1008205. Нужно просто в Advanced Settings выставить значение Disk.DiskMaxIOSize (значение в килобайтах). Некоторые массивы испытывают проблемы с производительностью, когда размер запроса ввода-вывода очень велик, поэтому здесь нужно обратиться к документации производителя массива. Если с помощью указанной настройки ограничить размер запроса ввода-вывода, то они будут разбиваться на маленькие подзапросы, что может привести к увеличению производительности подсистемы ввода-вывода на некоторых системах хранения. По умолчанию установлено максимальное значение в 32 МБ, что является достаточно большим (некоторые массивы начинают испытывать проблемы при запросах более 128 KB, 256 KB или 512KB, в зависимости от модели и конфигурации).

Однако вернемся к профилированию нагрузок по хранилищам в VMware vSphere. В одной из презентаций VMware есть замечательная картинка, отражающая численные характеристики производительности дисковых устройств в пересчете на шпиндель в зависимости от типа их организации в RAID-массивы:

Параметры в верхней части приведены для операций 100%-й последовательной записи для дисков на 15К оборотов. А в нижней части приведены параметры производительности для описанной выше "типичной" нагрузки, включая среднюю скорость чтения-записи, число операций ввода-вывода в секунду (IOPS) и среднюю задержку. Хорошая напоминалка, между прочим.

Теперь как анализировать нагрузку по вводу выводу. Для этого у VMware на сайте проекта VMware Labs есть специальная утилита I/O Analyzer, про которую мы уже писали вот тут. Она может многое из того, что потребуется для профилирования нагрузок по хранилищам.

Ну а дальше стандартные процедуры - балансировка нагрузки по путям, сторадж-процессорам (SP) и дисковым устройствам. Сигналом к изысканиям должен послужить счетчик Device Latency (DAVG) в esxtop, если его значение превышает 20-30 мс для виртуальной машины.

Вчера мы написали о новых возможностях Veeam Backup and Replication 6.1, которая вчера же стала доступна для загрузки. Новая версия продукта номер 1 имеет множество новых возможностей, и, помимо этого, включает бесплатное издание Veeam Backup Free Edition.

В таблице ниже приведены основные отличия коммерческой Veeam Backup and Replication и бесплатной Veeam Backup (обратите внимание, что в бесплатной версии слова Replication нет). Бесплатное издание построено на ядре знаменитой утилиты Veeam FastSCP, которой пользовались десятки тысяч администраторов для загрузки файлов на ESX / ESXi серверы. Теперь программисты Veeam привели ее в порядок, обновили механизмы работы через vSphere API, добавили некоторую функциональность от коммерческого Veeam B&R (например, VeeamZIP) и бесплатно отдают пользователям.

Посмотрим, что нам предлагают просто так:

Отметим, что вся функциональность Veeam Backup and Replication Standard полностью включена в издание Enterprise Edition, у которого значительно больше возможностей.

В итоге, в форме Veeam Backup Free Edition мы получили больше функций, чем в Veeam FastSCP, за что спасибо разработчикам. Важный момент: обновление с бесплатной версии Veeam Backup Free Edition до полноценного Veeam Backup and Replication происходит просто вводом лицензионного ключа, без необходимости переустановки продукта.

Бесплатный Veeam Backup Free можно скачать по этой ссылке: http://www.veeam.com/virtual-machine-backup-solution-free/download.html.

Коммерческий Veeam Backup and Replication можно скачать тут: http://www.veeam.com/vmware-esx-backup/download.html.